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REMARKS/ARGUMENTS 

Applicants thank the Examiner for his careful review of this application. Claims 1-20 
have been rejected. Claims 1 and 16 have been amended. Applicants respectfully request 
reconsideration of the application in view of the above amendment and the following remarks 
submitted in support thereof. 

Claim Rejections - 35 U.S.C. §112, second paragraph 

Claims 1-7 and 16-20 stand rejected under 35 U.S.C. §112, second paragraph, as 
being indefinite for failing to particularly point out and distinctly claim the subject matter 
which the Applicants regard as the invention. Although the Applicants believe that the 
original pending claims are defined over the art of record, the Applicants have amended 
independent claims 1 and 16 to clarify that the removal of the master/slave functionality is 
from the API components. As a result, Applicants respectfully request the Examiner to 
withdraw the 35 U.S.C. §112, second paragraph rejection for claims 1-7 and 16-20. 

Obviousness Rejections under 35 U.S.C. § 103(a) 

Claims 1, 6-9, and 14-15 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Java Media Framework API Guide (November 19, 1999) 
<http://java.sun.eom/products/javamedia/jmf/2. l.l/guide/JMFTOC.html> (herein referred to 
as "Java Guide") in view of U.S. Patent No. 6,138,271 to Keelev . Claims 2, 10, 16, and 20 
stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Java Guide in view of 
Keelev and U.S. Patent Publication No. 2004/0088710 to Ronkka et al . Claims 3-5 and 1 1- 
13 stand rejected under Java Guide in view of Keelev and Travostino et al ., Real-Time and 
Remote MACH IPC: Architecture and Design (April 8, 1994). Claims 17-19 stand rejected 
under 35 U.S.C. § 103(a) as being unpatentable over Java Guide in view of Keelev , Ronkka et 
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al., and Travostino et al . As will be fully explained below, the combination of Java Guide in 
view of Keelev and Ronkka et al . does not raise a prima facie case of obviousness against 
independent claims 1,8, and 16. 

Amended independent claims 1 and 16 define methods for creating a mobile 
multimedia framework application programming interface (API). In particular, API 
component access parameters are set to utilize a synchronous programming model. Further, 
API components are set to a pull data delivery protocol and master/slave functionality is 
removed from the API components. Independent claim 8 defines a mobile framework API 
that comprises a media engine. Similarly, the media engine has components that utilize a 
synchronous programming model. 

In support of the obviousness rejection, the Examiner noted that Java Guide teaches or 
suggests a synchronous programming model, as defined in independent claims 1, 8, and 16. 
Applicants respectfully traverse the Examiner's characterization in this regard because the 
portion of the reference relied upon by the Examiner (player and stop method at pages 11-12) 
does not teach or suggest a synchronous programming model. Specifically, Java Guide 
discloses "an asynchronous method on a Player" (page 12). In contrast, independent claims 
1, 8, and 16 define a synchronous programming model. An asynchronous method is simply 
different from a synchronous programming model. Furthermore, the term "synchronous" is 
not disclosed anywhere in Java Guide. Accordingly, Java Guide cannot reasonably be 
considered to teach or suggest to one having ordinary skill in the art a synchronous 
programming model, as defined in independent claims 1, 8, and 16. 

The Examiner also noted that Java Guide teaches or suggests setting the API 
components to a pull data delivery protocol, as defined in independent claims 1 and 16. 
Applicants respectfully traverse the Examiner's characterization in this regard because the 



Amendment 



Page 8 of 11 



Atty. Docket No. SUNMP010 



U.S. Application No. 09/930,850 
Amdt. Dated November 18, 2004 
Reply to Office Action of August 23, 2004 

portion of the reference relied upon by the Examiner (page 5) does not teach or suggest 
setting the API components to a pull data delivery protocol. In particular, at page 5, Java 
Guide discloses that "[m]edia data can be obtained from a variety of sources," such as "pull 
data sources: PullDataSource and PullBufferDataSource" and "push data sources; 
PushDataSource and PushBufferDataSource." Java Guide then briefly provides brief 
descriptions of the pull data source and the push data source. However, Java Guide does not 
disclose anywhere setting the API components to a pull data delivery protocol. Furthermore, 
if an assumption is made that Java Guide does disclose setting the API components to a pull 
data delivery protocol, then Java Guide must teach setting the push data source to a pull data 
source. However, setting the push data source to a pull data source is contrary to the 
teachings of Java Guide because, as discussed above, Java Guide particularly teaches that 
media data can be obtained from a variety of sources, such as a pull data source and a push 
data source. Accordingly, Java Guide cannot reasonably be considered to teach or suggest to 
one having ordinary skill in the art setting the API components to a pull data delivery 
protocol, as defined in independent claims 1 and 16. 

Furthermore, the Examiner noted that Keelev teaches or suggests removing 
master/slave functionality, as defined in independent claims 1 and 16. Again, the Applicants 
respectfully traverse the Examiner's characterization in this regard because the portions of the 
reference relied upon by the Examiner (col. 3, lines 37-39 and col. 7, line 64 - col. 8, line 3) 
do not teach or suggest removing master/slave functionality. In particular, the Examiner 
noted that Keelev discloses "removing functionalities that are not needed by the applications 
in the embedded computer" (see Office Action mailed August 23, 2004 at page 3). However, 
Keelev does not disclose anywhere that the functionalities include the master/slave 
functionality. Accordingly, Keelev cannot reasonably be considered to teach or suggest to 
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one having ordinary skill in the art removing the master/slave functionality, as defined in 
independent claims 1 and 16. Nonetheless, if the Examiner is actually asserting that 
removing master/slave functionality is not disclosed in Keelev but is obvious from the cited 
portions, then the Applicants ask the Examiner to specifically provide documentary evidence 
of the removal of the master/slave functionality in the next Office Action if the rejection is to 
be maintained (see M.P.E.P. §2144.03). 

To establish a prima facie case of obviousness, the prior art references must teach or 
suggest all the claim limitations (see M.P.E.P. §2143). Here, in view of the incorrect 
characterization of Java Guide and Keelev , the references as combined do not teach all the 
features of the claimed invention. 

Additionally, to establish a prima facie case of obviousness based on a combination of 
references, there must be some suggestion or motivation, either in the references or in the 
knowledge generally available to one having ordinary skill in the art, to combine the 
references in the manner proposed. The teachings of Java Guide focus on providing "a 
unified architecture and messaging protocol for managing the acquisition, processing, and 
delivery of time-based media data" (page 1). In contrast, the teachings of Keelev focus on 
operating systems that "provide a set of standard operations that may be invoked by an 
application program to perform routine tasks associated with controlling the computer 
hardware" (col. 1, lines 18-20). Managing time-based media and controlling computer 
hardware relate to entirely different technologies and applications. As the teachings of Java 
Guide have nothing to do with the problems addressed by Keelev , Applicants submit that 
there would not have been any motivation for one having ordinary skill in the art to combine 
Java Guide and Keelev in the manner proposed by the Examiner. 
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Accordingly, for the above-stated reasons, Applicants submit that independent claims 
1, 8, and 16 are patentable under 35 U.S.C. § 103(a) over Java Guide in view of Keelev and 
Ronkka et al . Claims 2-7, 9-15, and 17-20, each of which depends directly or indirectly from 
independent claims 1, 8, and 16, are likewise patentable under 35 U.S.C § 103(a) over Java 
Guide in view of Keelev , Ronkka et al ., and Travostino et al . for at least the same reasons set 
forth for independent claims 1, 8, and 16. As a result, Applicants respectfully request the 
Examiner to withdraw the 35 U.S.C. §103(a) rejections for claims 1-20. 

Conclusion 

In view of the foregoing, the Applicants respectfully submit that all the pending 
claims 1-20 are in condition for allowance. Accordingly, a Notice of Allowance is 
respectfully requested. If the Examiner has any questions concerning the present 
Amendment, the Examiner is requested to contact the undersigned at (408) 749-6900 ext. 
6924. If any additional fees are due in connection with filing this Amendment, the 
Commissioner is also authorized to charge Deposit Account No. 50-0805 (Order No. 
SUNMP010). A duplicate copy of the transmittal is enclosed for this purpose. 



Martine & Penilla, LLP 
710 Lakeway Drive, Suite 200 
Sunnyvale, California 94085 
Telephone: (408) 749-6900 
Customer Number 32,291 



Respectfully submitted, 
Martine & Penilla, L.L.P. 




Michael K. Hsu, Esq. 
Reg. No. 46,782 
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